home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / cstd.arc / CSTD8#2 < prev    next >
Encoding:
Internet Message Format  |  1985-07-28  |  4.8 KB
  1. From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
  2.  
  3.  
  4. mod.std.c Digest            Mon,  1 Jul 85       Volume 8 : Issue   2 
  5.  
  6. Today's Topics:
  7.              Section C.3.15 Conditional operator (2 msgs)
  8. ----------------------------------------------------------------------
  9.  
  10. Date: Thu, 20 Jun 85 20:58 EDT
  11. From: ihnp4!trwrb!trwspp!spp2!jhull
  12. Subject: Section C.3.15 Conditional operator
  13. To: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  14.  
  15. >Syntax
  16. > conditional-expression:
  17. >     logical-OR-expression
  18. >     logical-OR-expression ? logical-OR-expression : conditional-expression
  19. This allows a?b:c?d:e but not a?b?c:d:e, which seems strange, especially
  20. as I prefer the second.  (The first could be read as (a?b:c)?d:e, but
  21. the second is unambiguous).  I suggest changing the last line to
  22.       logical-OR-expression ? conditional-expression : conditional-expression
  23.  
  24. Mark,
  25.         I think you have missed the point.  There is (I think) no 
  26. sequence of productions which could result in the interpretation you
  27. show in parentheses above.  While a person reading the unparenthesized
  28. version might not know how the compiler would interpret it, the
  29. compiler would always produce the same result.  This is analogous to
  30. establishing precedence among arithmetic operators.
  31.         Furthermore, if your productions were adopted, ambiguity
  32. *would* result.  Let me abbreviate logical-OR-expression by l-e and
  33. conditional expression by c-e.  Let me call the first production above
  34. 1 & your recommended production 2.  Let me use a number in parentheses
  35. to designate which one of several identical non-terminal symbols on a
  36. line is to be replaced by that production.  Then,
  37.  
  38. 2       c-e ->
  39. 2(1)            l-e ? c-e : c-e
  40. 2(2)            l-e ? c-e : l-e ? c-e : c-e
  41. 1(1,2,3)        l-e ? l-e : l-e ? l-e : l-e
  42.                  a  ?  b  :  c  ?  d  :  e
  43. is clearly legal even though you don't like it.  But now we can see
  44. the ambiguity.  How do you parse that?  Do you reduce a?b:c before you
  45. reduce c?d:e or vice-versa?  Ambiguity in a grammar refers to the
  46. parser not being able to decide which production to apply to which
  47. token.  It does not refer to whether or not the programmer understands
  48. what the compiler is doing.
  49.  
  50. ------------------------------
  51.  
  52. Date: Sat, 29 Jun 85 17:35 EDT
  53. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  54. Subject: Section C.3.15 Conditional operator
  55. To: Jeff Hull <trwrb!trwspp!spp2!jhull@BERKELEY>
  56.  
  57. First off, I know that the compiler will not misinterpert a?b:c?d:e as
  58. (a?b:c)?d:e.  But the PROGRAMMER might.  To argue that this is no
  59. problem since the compiler will know what's going on is to miss the
  60. whole point.  (I seem to recall that there was once a language in which 
  61. "ELSE" meant "then in any case, do the following."  This was not usually
  62. what the writter of the program meant; the fact that the compiler "knew"
  63. what it was doing didn't prevent all the errors that naturally cropped
  64. when the programmer thought "ELSE" meant "else", and eventually it had
  65. to be changed. (Incidentally, does anyone else remember this or is it a
  66. figment of my imagination.))
  67.  
  68. Second, a?b:c?d:e *is* unambiguous, since my production is
  69.  
  70. cond-ex := *log-ex* ? cond-ex : cond-ex.  
  71.  
  72. The compiler may not reduce a?b:c first, since it's not a logical
  73. expression, which is required for the thing before the '?'.  So you must
  74. do c?d:e => cond-ex, then a?b:cond-ex => cond-ex.  If it does a?b:c =>
  75. cond-ex, its left with cond-ex?c:d, and loses.  Now, I see that it might
  76. be hard for the compiler to deduce this fact, but that didn't seem to be
  77. your point.
  78.  
  79. Now, personally, I'd be happy with
  80.  
  81. cond-ex := log-ex ? cond-ex : log-ex.
  82.  
  83. This forbids a?b:c?d:e, which is fine by me, and allows a?b?c:d:e.  One
  84. could even make a case for
  85.  
  86. cond-ex := cond-ex ? log-ex : log-ex,
  87.  
  88. which has the virtue that the compiler is allowed to reduce as soon as
  89. it can.  (a?b:c => cond-ex, now read ?d:e and reduce again.) But in the
  90. interests of clarity, perhaps the production should be
  91.  
  92. cond-ex := log-ex ? log-ex : log-ex.
  93.  
  94. This forces you to replace a?b:c:d:e with a?(b?c:d):e and a?b:c?d:e with
  95. a?b:(c?d:e).  In other words, it forces parens to be used, which is
  96. what you ought to be doing in the first place.  
  97.  
  98. Basically, my complaint is that the existing production encourages code
  99. that could be misread (and there doesn't seem to be any good reason for
  100. this) while not allowing the still unpleasant but somewhat nicer form
  101. that I prefer.
  102.  
  103.        Mark
  104. ^.-.^  Purtill at MIT-MULTICS.ARPA    **Insert favorite disclaimer here**
  105. (("))  2-032 MIT Cambridge MA 02139
  106.  
  107. ------------------------------
  108.  
  109. End of mod.std.c Digest - Mon,  1 Jul 85 09:57:50 EDT
  110. ******************************
  111.